|
项目场景：
MySql数据库操作，IN条件查询对应数据，更新到ES存储。
问题描述：
修改了IN中查询的条件，导致系统fullgc，重启系统之后当触发了该查询条件后，服务器立马又开始不断fullgc,导致服务整体不可用。
IN多条件查询类比如下场景1:
1. EXPLAIN SELECT * FROM test WHERE client_id in (0,1,2,3);
2. EXPLAIN SELECT * FROM test WHERE client_id in (0);
3. EXPLAIN SELECT * FROM test WHERE client_id in (1);
其中全表数据150w,client_id=0数据50w,其他条件数据均为1条，EXPLAIN结果如下：
场景1sql, 扫描全表，耗时较长；场景2sql, 走索引，耗时短；场景3sql, 走索引，耗时短。
原因分析：
经过一系列定位和几次重启观察，发现并不是系统发生了内存泄漏，而是由于IN查询语句并没有如预期走索引查询，而是进行了全表扫描。IN条件中当client_id=0时，有50w数据，全部加载到了内存，并且由于全表扫描，查询耗时较长，引发了系统连锁反应，最终导致系统不断进行fullgc，无法正常运行。
解决方案：
IN条件究竟是否走索引呢？
通常场景，IN条件查询走索引；当IN多条件查询时，如果数据量大于总数据量30%，就会走全表扫描(暂未找到官方结论，但在Mysql版本为8.0.18中，本人验证基本符合上述结论)；当IN是单条件，数据量大于总数据30%时，依然走索引。
最后的解决方案是对IN条件查询进行了优化处理，单独查询一次client_id=0对数据，进行Es同步； 优化了JVM内存分配，适当扩大新生代内存大小，让垃圾数据尽量控制在新生代回收。
|